Multi-stage authorisation system

ABSTRACT

A system for authorising smart cards via the Internet is provided, comprising a plurality of user stations ( 1 - 1 - 1 - n ) connected to a server ( 3 ) via the Internet ( 5 ). Each of the user stations ( 1 - 1;1 - n ) is attached to a card reader ( 7 - 1;7 - n ) suitable for reading data and accessing processing modules on smart cards ( 8 - 1 - 8 - m ). When a new card is to be issued, initially the server ( 3 ) generates and stores a task identifier as a task record ( 15 ) on a database ( 10 ) connected to the server ( 3 ). The task identifier is also dispatched to a user station ( 1 - 1; 1 - n ). A subsequent data submission by the user station ( 1 - 1; 1 - n ) is then required to include signed data incorporating authorisation data and the received task identifier. When all the data required for authorisation of a smart card ( 8 - 1;8 - m ) has been received, the server ( 3 ) checks the signed data to confirm each data submission comprises data incorporating a correct task identifier utilised for the current authorisation procedure.

[0001] The present invention concerns secure multi-stage authorisationsystems. In particular, the present invention concerns a securemulti-stage authorisation system in which data is transmitted over apublic network such as the Internet.

[0002] The Internet provides a convenient means by which data stored onremote computers may be accessed. However, the public nature of theInternet means that websites accessible by the Internet are exposed anddifficult to secure. Where a website contains sensitive data it istherefore essential to provide additional security to preventunauthorised access.

[0003] One means by which access to a website may be made secure is byuse of cryptographically enabled smart cards. Specifically,private/public key encryption modules may be provided by a smart card orother portable data processing device. The public/private key encryptionmodules can then be used to ‘sign ’and encrypt data which is transmittedover the potentially insecure connection.

[0004] In order for smart cards to prevent unauthorised access towebsites, it is necessary to ensure that smart cards for accessing aremote computer are only issued to authorised individuals. For thispurpose, smart card issuance and authorisation systems generally requirea number of multiple operations (e.g. collect data, authorise, witness,request certificate etc) to ensure that cards are not erroneously orfraudulently issued.

[0005] Although a multiple stage authorisation process can ensure a cardis not inappropriately issued, where multi-stage operations arethemselves effected across a public network such as the Internet it ispossible that the authorisation operations themselves may be interceptedand later duplicated to obtain fraudulent authorisation.

[0006] There is therefore a need for a multistage authorisation systemin which data may be transferred via a public network but which preventsfraudulent authorisation from being obtained.

[0007] In accordance with one aspect of the present invention there isprovided a data validation process comprising the steps of:

[0008] storing a task identifier on a server and dispatching a copy ofsaid task identifier to a remote station;

[0009] at said remote station, for a plurality of items of transactiondata, combining said task identifier with a said item of transactiondata and signing said combined data utilising an encryption method;

[0010] dispatching said signed data to said server together withidentification data; and

[0011] verifying the validity of the received signed data at saidserver, utilizing an encryption method selected on the basis of saididentification data received with signed data to determine if saidsigned data was generated from combined data incorporating said taskidentifier.

[0012] Further aspects and embodiments of the present invention willbecome apparent with reference to the following description andaccompanying drawings in which:

[0013]FIG. 1 is a schematic block diagram of a computer network inaccordance with a first embodiment of the present invention;

[0014]FIG. 2 is a schematic block diagram of task records and userrecords stored within a database of the computer network of FIG. 1;

[0015]FIG. 3 is a schematic block diagram of a smart card of FIG. 1;

[0016]FIG. 4 is a flow diagram of a card log in procedure;

[0017]FIG. 5 is a flow diagram of the processing of data to effect anindividual stage of a multi-stage authorisation process;

[0018]FIGS. 6A, 6B and 6C are schematic block diagrams illustrating thegeneration of data for dispatch across the public network of FIG. 1;

[0019]FIG. 7 is a flow diagram of the processing of an issuing programon the server of the computer network of FIG. 1;

[0020]FIG. 8 is a flow diagram of the processing of the issuing programon the server to determine whether a stage of multi-stage authorisationprocess is authorised;

[0021]FIG. 9 is a flow diagram of the processing of a user station inaccordance with a second embodiment of the present invention; and

[0022]FIG. 10 is a flow diagram of the processing of a server inaccordance with a second embodiment of the present invention.

[0023] First Embodiment

[0024]FIG. 1 is a schematic block diagram of a computer network inaccordance with a first embodiment of the present invention. Thecomputer network comprises a plurality of user stations 1-1-1-n that areall connected to a server 3 via the Internet 5. Individual smart cardreaders 7-1-7-n connected to each of the user stations 1-1-1-n areprovided enabling communication between a number of smart cards 8-1-8-mand the respective user stations 1-1-1-n. In this embodiment the smartcards 8-1-8-m each comprise cryptographically enabled smart cards forencrypting data utilizing conventional public/private key encryptiontechnology.

[0025] The server 3, in addition to being connected to the Internet 5 isalso connected to a database 10 which is arranged to store task records15 and user records 17. In the memories of each of the user stations1-1-1-n is stored a card interface module 20 and a browser program 22.Stored within the memory of the server 3 is an issuing program 24.

[0026] In accordance with this embodiment of the present invention, thecard interface module 20, browser program 22 and issuing program 24interact together with encryption modules provided on the smart cards8-1-8-m to enable data for effecting an update of user records 17 to betransmitted via the Internet 5 in a number of stages whilst preventingupdates from occurring if data transmitted via the Internet 5 isintercepted and modified or reused.

[0027] Specifically, the present embodiment will be described withreference to the process of updating user records 17 to effect issuingand authorising of new smart cards 8 for later access to the server 3and database 10. It will be appreciated that as issuance andauthorisation of a smart card normally enables the holder of the smartcard to access data, it is imperative that such a process is conductedin a secure manner. Although the present embodiment will be described interms of the issuance and authorisation of a smart card 8, it will beappreciated that the present invention is applicable to any processrequiring the secure transmission of multiple sets of data via a publicand therefore potentially insecure network.

[0028] In use, in this embodiment, the integrity of authorisation datais ensured in a number of ways. Initially, when a connection is firstmade between a user station 1-1;1-n and the server 3 a sessionidentifier is generated and stored within the database 10. A copy of thesession identifier is then dispatched and stored in the memory of theuser station 1-1;1-n making the connection. All subsequent transmissionsbetween the user station 1-1;1-n and the server 3 in the case of asession are then made to include this session identifier. Thus only auser station 1-1;1-n having a stored session identifier can submit dataand any data resubmitted from another session can be detected.

[0029] Additionally, whenever a new task is initiated by a user station1-1;1-n, for example the processing required to authorise a new smartcard 8, a unique task identifier is transmitted by the server 3 forinclusion in the next submission to be made in the session. These uniquetask identifiers are stored together with session identifiers as taskrecords 15 within the database 10. By requiring the inclusion of theappropriate task identifier in each data submission effecting a stage ina task, attempted resubmissions of data from other tasks within asession can be detected.

[0030] Finally, whenever data is submitted, the data including both thesession identifier and task identifier is required to be “signed” by theuser submitting the data by generating message hash data from thecomplete data submission including both the session identifier and taskidentifier. This message hash data is then encrypted, utilising anencryption module provided on the user's smart card 8. Thus in this waythe format and content of each data submission and the identity of thesmart card 8 utilised to submit the data can be confirmed.

[0031] When the issuing program 24 of the server 3 determines that datafor all stages of a task, for example a multiple stage authorisationprocess, have been received from a user station 1-1;1-n the receiveddata is checked to ensure that the session identifiers and taskidentifiers included within the received data correspond to a set ofsession identifiers and task identifiers stored as task records 15. Theissuing program 24 then confirms that decoding the message hash dataconfirms that the submission has not been altered and confirms theidentity of the smart card 8 utilised to submit the data. If the data isdetermined to be unaltered, the issuing program 24 then determineswhether the user as represented by data on the previously issued smartcard 8-1,8-n, utilised to generate the message hash has authority toauthorise the issuance of a card. If this is the case, the received datais then processed to generate a new user record 17 thereby activating anew smart card 8 for access to the server 3.

[0032] By providing a system in which all data submissions made by auser station 1-1 to the server 3 are made to incorporate a sessionidentifier and task identifier, a means is provided to detect there-submission of any data involved from an earlier authorisationprocedure. Thus in this way, every data submission made by a userstation 1-1;1-n to the server 3 is uniquely identified and locked intothe task and the session from which it originated. If for any reason adata submission is intercepted as it is transmitted via the Internet 5,the re-use of such data can be detected and unauthorised issuanceprevented. The complete authorisation process can therefore be effectedin a secure manner even if individual data submissions happen to beintercepted.

[0033] Prior to describing in detail the processing of the browserprogram 22 and the issuing program 24, data structures for the taskrecords 15 and user records 17 and the programs and data stored on asmart card 8 will first be described in detail with reference to FIG. 2.

[0034]FIG. 2 is a schematic block diagram of the content of database 10containing task record 15 and user records 17.

[0035] In this embodiment, each task record 15 comprises a sessionidentifier 32, a time stamp 33 and a task identifier 34. Whenever a userstation 1-1;1-n first accesses the server 3 via the Internet 5, a newtask record 15 comprising a newly generated session identifier 32, atime stamp 33 being the current time and a task identifier 34 is createdand stored in the database 10. Subsequently, whenever further a new taskis initiated by a user station 1-1;1-n in the course of that session,additional task records 15 are generated and stored comprising the samesession identifier 32, a new time stamp 33 and a task identifier 34 forthe new task. As will be described in detail later when an authorisationprocedure has been completed, the task records 15 are then utilised toconfirm that data has in fact been received from an authorisedindividual.

[0036] In addition to the task records 15, in this embodiment a set ofuser records 17 are also stored within the database 10. In thisembodiment, the individual user records 17 each comprise cardidentification data 42 for identifying a smart card 8, public key data44 for encrypting data and being part of a public/private key pair inwhich the private key data is stored on the smart card 8 identified bythe card identification data 42; authorisation data 46 being dataidentifying the processes the user represented by the user record 17 isauthorised to perform; and user details data 48 being data such as thename and address identifying individual to whom a smart card 8identified by the card identification data 42 has been issued.

[0037] As will be described in detail later in this embodiment the userrecords 17 are utilized to establish whether requests for issuingfurther smart cards 8 are valid. It will be appreciated that once a userrecord 17 linking a smart card 8 with authorisation data 46 has beengenerated and stored within the database 10, this database of authorisedand issued smart cards could be utilized to restrict access to datastored elsewhere on the database 10, the server 3 or any other system.

[0038]FIG. 3 is a schematic block diagram of program modules and datastored on a smart card 8. In this embodiment each of the smart cards8-1;8-m comprises a secure processing device that can process datatransmitted from a user station 1-1;1-n via a smart card reader 7-1;1-nattached to that user station 1-1;1-n. Each of the smart cards 8 in thisembodiment is arranged to store card identification data 42 being datafor identifying the smart card 8 and the authorised user of the smartcard 8 to the server 3; a personal identification number 52 being anumber to be entered by the authorised user of a smart card 8 toauthorise access to the encryption processes provided by the smart card8; a login module 53 for controlling access to the encryption processesprovided by the card 8, an encryption module 54 and public key 55 andprivate key data 56 for encrypting data; and an enabled/disabled flag58.

[0039] By providing an encryption module 54 and public and private keydata 55;56 on the smart card a means is provided to enable the user of asmart card 8 to sign data for transmission thereby confirming that thedata has indeed been authorised by the holder of the smart card 8.

[0040] When a smart card 8 is inserted within a smart card reader7-1;7-n, access to modules and data stored on the smart card 8 iseffected by the user station 1-1;1-n to which the smart card reader7-1;7-n is attached. In this embodiment, access to data and programmodules provided on the card 8 is controlled by the interaction of thecard interface module 20 and the login module 53. Together, as will bedescribed, these programs interact to require a user to enter datacorresponding to the personal identification number 52 stored on thecard 8. The fact that data corresponding to the pin number 52 has beenentered is then recorded by the status of the enabled/disabled flag 58.

[0041]FIG. 4 is a flow diagram of the processing of the interactionbetween the card interface module 20 on a user station 1-1;1-n and alogin module 53 provided on a smart card 8. Initially (S4-1) the cardinterface module 20 causes the user station 1-1;1-n to display to a usera request to insert a smart card 8 into the smart card reader 7-1;7-nattached to the user station 1-1;1-n.

[0042] The card interface module 20 then (S4-2) causes the user station1-1;1-n to determine whether a smart card 8 is presently inserted withinthe smart card reader 7-1;7-n attached to the user station 1-1;1-n. Ifthis is not the case the card interface module 20 causes (S4-1) arequest that a smart card 8 be inserted into the smart card reader7-1;7-n to be displayed to the user once again before again determining(S4-2) whether a smart card 8 has indeed been inserted into the reader7-1;7-n attached to the user-station 1-1;1-n.

[0043] When the card interface module 20 determines that a smart card 8is present within the smart card reader 7-1;7-n attached to the userstation 1-1;1-n, the card interface module 20 then (S4-3) causes aprompt to be displayed to a user to prompt the user to enter a personalidentification number into the user station 1-1;1-n.

[0044] When a personal identification number is entered into the userstation 1-1;1-n, this is then submitted to the login module 53 providedon the card 8 in the smart card reader 7-1;7-n attached to the userstation 1-1;1-n, which (S4-4) compares the entered identification numberwith the personal identification number 52 stored on the smart card 8.

[0045] If the login module 53 determines that the personalidentification number received from the user station 1-1;1-n does notcorrespond to the personal identification number 52 stored on the smartcard, the login module 53 then causes the card interface module 20 toredisplay the request to input an identification number (S4-3) and whena new number is entered and submitted to the login module 53, the loginmodule 53 rechecks (S4-4) the new identification number entered by auser.

[0046] If the login module 53 determines that the identification numberentered by a user into the user station 1-1;1-n corresponds to thepersonal identification number 52 stored on the smart card 8, the loginmodule 53 then sets (S4-5) the enabled/disabled flag 58 on the smartcard 8 to enabled to permit the user station 1-1;1-n to access theencryption module 54 on the smart card 8.

[0047] After access to the encryption module 54 on a smart card 8 hasbeen enabled, in this embodiment a user can cause the browser program 22to transmit a session request which is transmitted via the Internet 5 tothe server 3. As will be described in detail later, in response to thedispatch of an initial session request, the server 3 generates a newsession identifier which is transmitted to the user station 1-1;1-n forincorporation in subsequent data transactions from the user station1-1;1-n to the server 3. The initial session request also causes theserver 3 to generate and dispatch data for generating an initial userinterface and a task identifier for effecting an initial stage of anauthorisation procedure which is then processed by the browser program22.

[0048]FIG. 5 is a flow diagram of the processing of the browser program22 in accordance with this embodiment of the present invention. In thisembodiment the browser program 22 is invoked whenever a user station1-1;1-n receives data for generating a user interface for example anHTML script and task identifier from the server 3.

[0049] When the user station 1-1;1-n receives data from the server 3 viathe Internet 5 comprising a task identifier and data for generating auser interface, initially (S5-1) the task identifier is stored withinthe memory of the user station 1-1.

[0050] The user station 1-1;1-n then (S5-2) proceeds to generate anddisplay a user interface utilizing the received data for generating auser interface such as an HTML script in a conventional manner. In thisway a user interface is displayed to a user into which a user can enterdata for example name and address data and data identifying authorisedactions for subsequent storage as a user record 40. Alternatively, inthe case of some data for dispatch when issuing a new smart card 8, forexample the card identification number 42 or a public key 55 for publickey encryption stored on a new smart card 8, the user interface wouldprompt a user to insert the smart card 8 being authorised into the cardreader 7-7;7-n and access data on the new smart card 8 to obtainrequired data for dispatch.

[0051] When data for dispatch has been obtained utilising the userinterface the browser program 22 then (S5-3) proceeds to generate outputdata for dispatch back to the server 3. FIGS. 6A, 6B and 6C areschematic block diagrams illustrating the generation of data fordispatch. In this embodiment initially the browser program 22 processesthe user inputs, for example text data entered into windows orselections made from a menu generated from the received HTML script ordata obtained from a new smart card 8 to generate transaction data 60for dispatch as is shown in FIG. 6A.

[0052] After the transaction data 60 has been generated, the browserprogram 22 in this embodiment proceeds to append to the transaction data60 a copy of the session identifier 62 for the current session betweenthe user station 1-1;1-n and the server 3 which is currently storedwithin the memory of the user station 1-1, and a copy of the taskidentifier 64 stored within the memory of the user station 1-1, whichhad previously been received together with the latest user interface.The browser program 20 then appends to the transaction data 60, sessionidentifier 62 and task identifier 64, a copy of the card identificationdata 42 of the smart card 8 utilised to initiate the access session withthe server 3. FIG. 6B illustrates the input data 60 to which the sessionidentifier, 62 task identifier 64, and card identification data 42 havebeen appended.

[0053] Having appended the session identifier 62, task identifier 64 andcard identification data 42 to the transaction data 60 for dispatch, thebrowser program 22 then (S5-4) generates a message hash from thecombined and appended transaction data 60, session identifier 62, taskidentifier 64 and card identification data 42. This message hash isgenerated in a conventional way which generates a code number utilizingthe transaction data 60, session identifier 62, task identifier 64 andcard identification data 42 which is dependent upon the exactconstitution of the input data 60, session identifier 62, taskidentifier 64 and card identification data 42 so that small variationsin the data cause substantially different message hashes to begenerated.

[0054] Finally, the browser program 22 then proceeds to obtain anencrypted form of this calculated message hash by providing the messagehash to the encryption module 54 on the smart card 8 within the reader7-1;7-n associated with the user station 1-1;1-n. Provided this smartcard 8 has been enabled as identified by the enabled/disabled flag 58,this causes encryption module 54 of the smart card 8 to process themessage hash to generate an encrypted message hash 66, utilising theprivate key data 56 stored on the smart card 8. This encrypted messagehash 66 is then appended to the input data 60, session identifier 62,task identifier 64 and card identification data 42 as is illustrated inFIG. 6C.

[0055] The entirety of the transaction data 60, session identifier 62,task identifier 64 card identification data 42 and encrypted messagehash 66 is then dispatched to the server 3 via the Internet 5.

[0056] By incorporating the session identifier 62 and task identifier 64within the data dispatched from a user station 1-1;1-n to the server 3,a means is provided to associate each submission of data from a userstation 1-1;1-n with a particular access session and task made during anaccess session.

[0057] By providing a means for generating a message hash which issensitive to amendments of data utilized to generate the message hash,it is possible to ensure that once the transaction data 60, sessionidentifier 62 task identifier 64 and card identification data 42 havebeen appended no further amendments occur to the transaction data 60,session identifier 62, task identifier 64 or card identification data 42subsequent to the generation of the message hash. This is possiblebecause any such amendments would cause a different message hash valueto be determined for the amended data.

[0058] Finally, by encrypting the message hash utilizing the encryptionmodule 54 and private key data 56 on the smart card 8 within the cardreader 7-1;7-n associated with the user station 1-1;1-n making thesubmission, a means is provided to ensure that the user making thesubmission is in possession of a valid and authorised smart card 8 andthat subsequently the submitted data cannot be repudiated by the holderof the smart card 8 as not having originated with the consent of thatuser. Thus in this way if the data transmitted via the Internet 5 isintercepted, it is not possible for the data to be amended and thensuccessfully resubmitted to the server 3.

[0059]FIG. 7 is a flow diagram of the processing of the issuing program24 in accordance with this embodiment of the present invention. Theissuing program 24 is invoked whenever the server 3 receives data from auser station 1-1;1-n via the Internet 5.

[0060] Initially (S7-1) when data is received, the issuing program 24causes the server 3 to determine whether the received data comprises aninitial session request and card identification data 42 sent from a userstation 1-1;1-n.

[0061] If the data received by the server 3 from the Internet 5comprises an initial session request and card identification data 42,the issuing program 24 then (S7-2) causes the server 3 to generate a newtask record 15 comprising a newly generated session identifier 32 a timestamp 33 being the current time indicated by the server 3 and an initialtask identifier 34. The issuing program 24 then dispatches a copy of thesession identifier 32 and the task identifier 34 together with an HTMLscript for generating an initial user interface for entering data forauthorising a smart card 8 via the Internet 5 back to the user station1-1;1-n from which the session request and the card identification data42 had been received. The processing of the issuing program 24 thenends.

[0062] If when data is initially received by the server 3, the data isdetermined (S7-1) not to be an initial session set-up request, theissuing program 24 then (S7-6) proceeds to store the data received fromthe Internet 5.

[0063] After the received data has been stored, the issuing program 24then proceeds to determine (S7-7) whether all the data necessary forissuing a smart card 8 has been received from the user station 1-1 viathe Internet 5.

[0064] In this embodiment this is achieved by the issuing program 24determining whether the database 10 has stored within it a number oftask records 15 having the session identifier 32 corresponding to thesession identifier 62 received as part of data received from theInternet 5 which corresponds to the number of data exchanges required toeffect the multi-part authorisation required for issuing a smart card.

[0065] If this is not the case, the issuing program 24 then (S7-8)utilises the task identifier 64 of the received data to select a userinterface corresponding to the next task and generates a new taskidentifier 34 for the next task which is then stored together with thesession identifier 62 of the received data and a time stamp 33indicating the current time as a new task record 15. This taskidentifier 34 is then dispatched together with the next user interfacefor effecting the next stage in the multistage authorisation procedurebeing effected. The processing of the issuing program then ends.

[0066] If after data corresponding to part of an authorisation procedurehas been received by the server 3, the issuing program 24 determines(S7-7) that data has been received for all of the stages of anauthorisation procedure, the issuing program 24 then (S7-9) determineswhether all the items of data which have been received are valid.

[0067] In this embodiment, the issuing program 24 determines whetherdata received is valid data independently for each set of data receivedvia the Internet 5.

[0068]FIG. 8 is a flow diagram of the processing by the issuing program24 to determine the validity of received data. The processing of FIG. 8occurs in relation to each set of data constituting part of a multi-partauthorisation procedure.

[0069] Initially (S8-1), in this embodiment, the issuing programdetermines whether any of the task records 15 stored in the database 10include a time stamp 34 indicating a time older than a default value,for example 15 minutes. If this is the case, the server 3 assumes thatthe session for which the task record 15 was generated has beeninterrupted and therefore the server 3 proceeds to delete all the taskrecords 15 including the session identifier 32 corresponding to thesession identifier 32 of the task record 15 having an out of date timestamp 34. Thus, in this way the issuing program 22 ensures that thedatabase 10 is periodically purged of unused task records 15 and alsothe security of the system is increased as each session is limited induration unless authorisations are regularly completed.

[0070] The issuing program 24 then (S8-2) causes the server 3 for eachitem of stored received data including a session identifier 62corresponding to the session identifier 62 of the most recently receivedset of data to determine whether the session identifier 62 and taskidentifier 64 of each set of received data corresponds to the sessionidentifier 32 and task identifier 34 of a task record 15 stored withinthe database 10. If this is the case, the task record 15 including thesession identifier 32 and task identifier 34 is then deleted from thedatabase 10.

[0071] The issuing program 24 then (S8-3) determines whether the messagehash data 66 included within each stored data set is valid. In thisembodiment, this is determined by the server 3 initially decrypting theencrypted message hash 66 of the stored data set utilising the publickey 44 of a user record 17 incorporating the card identification data 42corresponding to the card identification data 42 included within thereceived set of data. The server 3 then proceeds to generate a messagehash from the stored transaction data 60, session identifier 62, taskidentifier 64 and card identification data 42 in the same way which haspreviously been described in relation to the processing by the browserprogram 22. The data generated by decrypting the encrypted message hash66 and the generated new message hash from the other data within thedata set are then compared. If these are identical, this indicates thatthe received set of data was also used to generate the message hashencrypted utilising the private key 56 on the smart card 8 identified bythe card identification data 42 in the data set and that none of thedata within the other data set has been amended after dispatch from theuser station 1-1;1-n.

[0072] Finally, after the validity of the task identifier 64 and sessionidentifier 62 in the received data set has been confirmed and themessage hash checked, the issuing program 24 then (S8-4) determineswhether the authorisation data 64 within the user record 40incorporating the card identification data 42 corresponding to the cardidentification data 42 in the received data set includes dataidentifying the user of that card as being authorised to issue a newsmart card. If this is the case, the server 3 records (S8-5) that thedata set under consideration is correctly authorised.

[0073] If, however, either the task identifier 62 or task identifier 64are not determined to be valid or the message hash 66 is determined notto be correct or the authorisations 64 for a user are insufficient, theserver 3 records the data set as unauthorised (S8-6). This process isthen repeated for each of the subsequent data sets received for all thestages of the authorisation.

[0074] Returning to FIG. 7, after the validity of each of the data setsinvolved in a multi-stage authorisation process have been determined,the issuing program 24 then (S7-10) determines whether the entiretransaction for generating a new user record 17, and thereby authorisinga new smart card 8, is authorised. If this is the case, the server 3then (S7-11) proceeds to generate a new user record 17 comprising a cardidentification number 42, public key data 44, authorisation data 46 anduser details 48 from the received transaction data 60 whose validity hadbeen confirmed.

[0075] Although in the above embodiment an authorisation procedure hasbeen described in which steps in an authorisation procedure areperformed sequentially, the present invention is particularly applicableto systems in which stages of an authorisation procedure can be effectedin any order. A second embodiment will now be described in which theorder of stages in an authorisation procedure may be varied.

[0076] Second Embodiment

[0077] In this embodiment of the present invention the hardware providedcorresponds to the hardware in the first embodiment as shown in FIG. 1and description of the hardware will not be repeated here. However, theprocessing by the browser program 22 and issuing program 24 is amendedto enable the user to vary the order in which tasks in a multi-stageauthorisation process are performed.

[0078]FIG. 9 is a flow diagram of the processing of a user station1-1;1-n in accordance with this embodiment of the present invention.Initially (S9-1) the browser program 22 of the user station 1-1;1-n isutilized to access the server 3 via the Internet 5 in a conventionalmanner. As a result of a connection being established between the userstation 1-1;1-n and the server 3 the server 3 dispatches a sessionidentifier 32 and task identifier 34 to the user station 1-1 togetherwith a user interface to effect a login request.

[0079] When the session identifier 32 and task identifier 34 arereceived and stored within the memory of the user station 1-1 thebrowser program 22 then utilizes the received login user interface toinitiate a card login procedure (S9-2) similar to the card loginprocedure previously described with reference to FIG. 4.

[0080] After a user has completed the card login procedure and istherefore able to pass data from the user station 1-1;1-n to theencryption module 54 of a smart card 8-1;8-m inserted within the reader7-1;7-n attached to the user station 1-1;1-n, a user is prompted toidentify which task they wish to perform by selecting the task from theuser interface generated by the browser 22 from the data received fromthe server 3. When a task has been selected the browser program 22 thendispatches transaction data 60 comprising the new task request togetherwith a copy of the session identifier 32 and task identifier 34, a cardidentification number 42 and an encrypted message hash 66 in a similarway as has been described in the previous embodiment.

[0081] This data is then received and processed by the server 3 which inresponse dispatches a new task identifier 34 and an initial userinterface for the selected task to the user station 1-1;1-n making thenew task request. When (S9-4) this new task identifier and initial userinterface are received by the user station 1-1;1-n, the new taskidentifier 34 is stored within the memory of the user station 1-1;1-nand the initial user interface for the selected task is displayed to auser.

[0082] In this embodiment, each of the user interfaces dispatched by theserver 3 via the Internet 5 to a user station l-1;1-n comprise userinterfaces enabling a user to either select a new task, end an accesssession or enter data for effecting an authorisation procedure as partof a task being undertaken. If a user selects to perform a new task onthe user interface (S9-5) this causes the user station 1-1 to dispatchtransaction data 60 comprising a request for the new task together withthe session identifier 32 and task identifier 34 currently stored withinthe memory of the user station 1-1;1-n together with a card identifier42 and an encrypted message hash 66 the same way as has previously beendescribed to the server 3 via the Internet 5. In response to receivingsuch data the server 3 outputs a new task identifier 34 and initial userinterface for the newly selected task and data identifying the step in aprocess the user interface is to be utilized to effect. These arereceived by the user station 1-1;1-n and processed in a similar way inwhich the initial user interface received following the login procedureis processed (S9-4).

[0083] If utilizing the user interface displayed on the user station1-1;1-n a user selects to end a session (S9-6) the processing of thebrowser program 22 finishes.

[0084] If the user does not select a new task to be initiated (S9-5) andthe user does not make a selection to end the current session (S9-6) butinstead (S9-7) the user enters data utilizing the currently displayeduser interface when data has been entered to effect a portion of a taskthis is then dispatched as transaction data 60 together with a copy ofthe session identifier 62 and task identifier 64 currently in memory,card identification data 42 and an encrypted message hash 66 in the sameway as has been described in relation to the first embodiment.Additionally, in this embodiment the browser 22 also dispatches dataidentifying the step in a process the transaction data 60 represents.

[0085] In response to receiving transaction data 60 the server 3 thenoutputs the next user interface to effect the next stage in thecurrently selected authorisation process. When this is received (S9-8)it is displayed by the user station 1-1;1-n the user can again eitherselect to initiate a new task (S9-5) select to end the current session(S9-6) or enter further data to be transmitted as transaction data(S9-7).

[0086] Thus in this way by linking some stages in an authorisationprocedure as part of the same task for example data entry and thewitnessing/authorisation of that data entry where such steps must occurin the specified order the processing of an authorisation procedure inthis way ensures that the order in which these steps take place ismaintained.

[0087] However, by dividing other parts of an authorisation procedure,for example, separate authorisation/witnessing steps between differenttasks and enabling a user to select which task is to be performed aflexible work flow can be achieved.

[0088]FIG. 10 is a flow diagram of the processing of an issuing program24 on a server 3 in accordance with this embodiment of the presentinvention. As in the previous embodiment the issuing program 24 isinitiated whenever the server 3 receives data from the Internet 5.Initially, when data is received (S10-1) the issuing program 24determines whether the data received comprises a new session request. Ifthis is the case the server then (S10-2) proceeds to generate a taskrecord 15 in a similar manner that is described in the first embodimentand dispatch a copy of the session identifier 32 and task identifier 34of the newly generated task record 15 back to the user station 1-1;1-nfrom which a session request has been received together with a userinterface for effecting a card login request. The processing of theissuing program 25 then ends.

[0089] If, the issuing program 24 determines that received data does notcorrespond to a new session request the issuing program 24 then (S10-3)determines whether the transaction data 60 received comprises a requestto initiate a new task. If this is the case the issuing program 24 then(S10-4) generates a new task record comprising a new task identifier 34and the session identifier 32 corresponding to the session identifier 62received together with the new task request in the same manner in whichthe task record has been described as being generated in the previousembodiment. The issuing program 24 then dispatches a copy of the taskidentifier 34 of the newly generated task record 15 together with aninitial user interface for the requested task. The processing of theissuing program 24 then ends.

[0090] If the issuing program 24 determines that transaction data 60received from the Internet 5 comprises neither a new session request nora new task request, the issuing program 24 then (S10-5) determineswhether the transaction data 60 included within the data received fromthe Internet 5 comprises an instruction that the data necessary toeffect a task has been received and that the received data should now beprocessed. If this is not the case the issuing program 24 then storesthe received transaction data 60, session identifier 62, task identifier64, card identification data 42 and encrypted message hash 66 and thendispatches the next user interface for inputting data to effect the nextstage in the task selected utilizing the data identifying the step thereceived transaction data 60 is intended to represent. The processing ofthe issuing program 24 then ends.

[0091] If, however, the issuing program 24 determines that thetransaction data 60 received comprises an instruction that all of thedata necessary to effect an authorisation procedure has been receivedand that a task is therefore complete the issuing program then (S10-7)proceeds to determine whether the received transaction data 60 necessaryto effect the authorisation procedure is indeed valid and that thetransaction is therefore authorised (S10-8) and if so update the userrecord accordingly (S10-9) in a similar way in which the validity ofreceived transaction data is determined as has been described in thefirst embodiment. However, in this embodiment the deletion of the taskrecords 15 including task identifiers 34 corresponding to a taskidentifier 64 inn stored received data occurs only after the validity ofall of the stored data for effecting a task in an authorisationprocedure has been checked. This is because in this embodiment, a singletask record 15 is generated for each task in a procedure rather than foreach data submission as was described in the first embodiment. After anyauthorised updates of the user records 17 have occurred, the processingand the issuing program 24 then ends.

[0092] Amendments and Modifications

[0093] Although the present invention has been described in relation tosystems for issuing smart cards, it will be appreciated that it is alsoapplicable to other on-line systems, for example e-commerce systems inwhich multiple data sets are transmitted via the Internet. The presentinvention is also applicable to networks other than the Internet such asinternal Intranets or other communications systems such as telephonysystems.

[0094] Although in the above embodiments systems have been describedwhich data transmitted from a user station 1-1;1-n is transmitted in anunencrypted form, it will be appreciated that in other embodiments foradditional security prior to dispatch via the Internet 5, the browserprogram 22 could be arranged to encrypt all the data being sent to theserver 3 and the server 3 could be arranged to decrypt any data receivedfrom the Internet 5.

[0095] Although in the above embodiments, the checking of time stamps 33is described as occurring whenever a task is to be validated, it will beappreciated that deletion of time expired task records 15 could occurperiodically instead.

[0096] Although in the above embodiments, task records 15 and userrecords 17 have been described as both being stored on a database 10separate from the server 3, the database 10 could be arranged only tostore the user records 17 with task records being stored on the server3. An advantage of such an arrangement would be that access to thedatabase 10 would be limited to determining whether transactions wereauthorised. The amount of data traffic between the server 3 and database10 would therefore be reduced and the security of the database 10enhanced.

[0097] Although the above embodiments have been described with referenceto public/private key encryption systems and smart cards 8, any suitableencryption schemes could be utilized. For example, encryption schemesbased on passwords could be used.

[0098] Alternatively, instead of utilising a smart card 8 and smart cardreader 7-1;1-n, encryption using a separate hand held encryption devicecould be used. In such a system message hash data would be generated bya user station 1-1;1-n and displayed to a user. The displayed messagehash data, would then be entered into the separate encryption devicewhich would process the data to generate encrypted data which would thenbe displayed to a user to enable the user to enter the data into theuser station 1-1;1-n for inclusion in data dispatched to a server. Insuch a system no direct communication occurs between the user station1-1;1-n and the encryption device and hence security is increased.

[0099] Also, although confirmation of the validity of a databasesubmission has been described in terms of decrypting an encryptedmessages hash, it will be appreciated that confirmation could beachieved by a server repeating the message hash generation andencryption process performed at a user station 1-1;1-n and comparison ofthis encrypted message hash with received encrypted message hash couldoccur.

[0100] Alternatively, instead of encrypting only the message hash theentirety of the transaction data, session identifier, task identifierand message hash could be encrypted. Upon receipt decryption of thecombined data could occur based upon a decryption method selectedutilizing received card identification data and then the validity of themessage hash could be confirmed to ensure the received encrypted datahad not been amended.

[0101] Although the embodiments of the invention described withreference to the drawings comprise computer apparatus and processesperformed in computer apparatus, the invention also extends to computerprograms, particularly computer programs on or in a carrier, adapted forputting the invention into practice. The program may be in the form ofsource or object code or in any other form suitable for use in theimplementation of the processes according to the invention. The carrierbe any entity or device capable of carrying the program.

[0102] For example, the carrier may comprise a storage medium, such as aROM, for example a CD ROM or a semiconductor ROM, or a magneticrecording medium, for example a floppy disc or hard disk. Further, thecarrier may be a transmissible carrier such as an electrical or opticalsignal which may be conveyed via electrical or optical cable or by radioor other means.

[0103] When a program is embodied in a signal which may be conveyeddirectly by a cable or other device or means, the carrier may beconstituted by such cable or other device or means.

[0104] Alternatively, the carrier may be an integrated circuit in whichthe program is embedded, the integrated circuit being adapted forperforming, or for use in the performance of, the relevant processes.

1. A method of confirming the validity of a plurality of items oftransaction data transmitted from a remote station to a server across anopen communications network, said method comprising the steps of: atsaid server, storing a task identifier and dispatching a copy of saidtask identifier to said remote station; at said remote station, for eachof said items of transaction data, generating signature data byencryption of a said item of transaction data combined with said taskidentifier and dispatching a data set comprising said encryptedsignature data, said item of transaction data and identification data tosaid server; and at said server, receiving said dispatched data sets,and for each received data set, selecting an encryption method on thebasis of identification data in said data set, and determining thevalidity of an item of transaction data in said data set by utilisingsaid selected encryption method to determine whether received encryptedsignature data in said data set corresponds to data generated fromcombined data incorporating said stored task identifier.
 2. A method inaccordance with claim 1, wherein said determining step comprises thesteps of: utilizing said selected encryption method to decrypt saidsignature data; and identifying whether decrypted signature datacorresponds to data obtained from processing combined data comprisingsaid item of transaction data and said task identifier.
 3. A method inaccordance with claim 2, wherein said generation of signature datacomprises the steps of: generating message hash data by processing asaid item of transaction data combined with said task identifier inaccordance with a message hash generation method; and encrypting saidgenerated message hash data; and wherein said identifying step comprisesthe steps of: generating further message hash data by processing a saidreceived item of transaction data combined with said task identifier inaccordance with said message hash generation method and comparing saidfurther message hash data with said decrypted signature data.
 4. Amethod in accordance with claim 2, wherein said generation of signaturedata comprises encrypting said transaction data combined with said taskidentifier.
 5. A method in accordance with claim 1, wherein saiddetermining step comprises the steps of: utilizing said selectedencryption method to generate further signature data by processingcombined data comprising a said item of transaction data and a said taskidentifier in a received data set; and identifying whether said furthersignature data corresponds to said signature data in said received dataset.
 6. A method in accordance with claim 5, wherein said generation ofsignature data comprises the steps of: generating message hash data byprocessing a said item of transaction data combined with said taskidentifier in accordance with a message hash generation method; andencrypting said generated message hash data; and wherein said generationof further signature data comprises the steps of: generating furthermessage hash data by processing a said item of transaction data combinedwith a said task identifier in a received data set in accordance withsaid message hash generation method and encrypting said further messagehash data utilizing said selected encryption method.
 7. A method inaccordance with claim 1, wherein said encryption of a said item oftransaction data combined with said task identifier comprises encryptingsaid combined data utilizing a data processing device accessible by saidremote station.
 8. A method in accordance with claim 7, wherein saiddata processing device comprises a smart card.
 9. A method in accordancewith any of claim 1, wherein said encryption of a said item oftransaction data combined with said task identifier comprises the stepsof: providing a separate encryption device; inputting datarepresentative of said item of transaction data and said task identifierinto said encryption device; utilising said encryption device to encryptsaid input data and display encrypted data; and inputting displayedencrypted data into said remote station.
 10. A method in accordance withclaim 1, wherein said storing step comprises storing a task identifierin association with time stamp data indicative of a time of storage andwherein said determining step comprises determining whether time stampdata associated with a task identifier associated with receivedtransaction data is indicative of a time of storage greater than apredetermined time period before receipt of said received transactiondata.
 11. A method in accordance with claim 1, further comprising thestep of: at said server, in response to receiving at least some of saiddata sets, storing a task identifier and dispatching a copy of said taskidentifier to said remote station; wherein said remote station generatessignature data utilizing the most recently dispatched task identifier.12. A method in accordance with claim 11, further comprising the stepof: dispatching with said copy of said task identifier means forgenerating user interface means at said remote station; and utilizingsaid user interface means to generate an item transaction data fordispatch to said server.
 13. A method in accordance with claim 1,wherein said task identifier comprises a first portion and a secondportion wherein said first portion comprises fixed data and said secondportion comprises variable data.
 14. A method in accordance with claim1, further comprising the step of: if a said received data set isdetermined to be valid, utilizing said transaction data.
 15. A method inaccordance with claim 13, said utilisation of said transaction datacomprises generating or modifying a record in a database.
 16. A methodin accordance with claim 1, wherein said transaction data comprises dataindicative of a smart card authorisation.
 17. A server for confirmingthe validity of a plurality of items of transaction data to be utilizedin a process, said server comprising: a data store able to store taskidentification data associated with steps in a process to be performed,prior to performance of said process; a receiver for receiving aplurality of data sets, each of said data sets comprising encryptedsignature data, an item of transaction data and identification data; aselector operable to select an encryption method on the basis ofidentification data in a data set received by said receiver; and avalidator operable to determine the validity of a plurality of items oftransaction data from a plurality of data sets received by said receiverto be utilized in a process to be performed, wherein said validator isoperable to determine the validity of said data by utilising encryptionmethods selected by said selector to determine for items of transactiondata in each data set, whether encrypted signature data in a said dataset received by said receiver corresponds to data generated fromcombined data incorporating task identification data stored in said datastore associated with respective steps in a process to be performed. 18.A server in accordance with claim 17, wherein said validator comprises:a decryptor operable to decrypt signature data in a data set received bysaid receiver utilising an encryption method selected by said selectorfor identification data in said data set; and a correspondencedeterminator operable to determine whether decrypted signature datacorresponds to data obtained from processing combined data comprising anitem of transaction data in said data set including said signature dataand task identification data for a step in a process to be performedstored in said data store.
 19. A server in accordance with claim 18,wherein said validator further comprises a message hash generatoroperable to generate message hash data by processing an item oftransaction data in a received data set combined with taskidentification data associated with a step in a process to be performedstored in said data store, wherein said comparator is operable tocompare said generated message hash data with decrypted signature datadecrypted by said decryptor.
 20. A server in accordance with claim 17,wherein said validator comprises: a signature generator operable toprocess combined data comprising an item of transaction data and taskidentification data in a data set received by said receiver; and acomparator operable to compare signature data generated by saidgenerator with signature data in said data set received by saidreceiver.
 21. A server in accordance with claim 20, wherein saidsignature data generator comprises: a message hash generator operable togenerate message hash data by processing an item of transaction data ina data set received by said receiver combined with task identificationdata in said received data set; and an encryptor operable to encryptsaid message hash data utilising said encryption methods selected bysaid selector.
 22. A server in accordance with claim 17, wherein saiddata store is operable to store said task identification data inassociation with time stamp data indicative of a time of storage, andwherein said validator is operable to determine the validity of an itemof transaction data in a data set received by said receiver bydetermining whether time stamp data associated with a task identifierwithin a data set received by said receiver including said item oftransaction data is indicative of a time of storage greater than apredetermined time period before receipt of said received data set. 23.A server in accordance with claim 17, further comprising a taskidentification data dispatcher for dispatching a copy of a taskidentification data for a step in a process to be performed stored insaid data store, upon receipt of the data set for a previous step insaid process by said receiver.
 24. A server in accordance with claim 23,wherein said dispatcher is further operable to dispatch data forgenerating a user interface for inputting items of transaction data fora subsequent step in said process.
 25. A server in accordance with claim17, wherein said data store is operable to store task identificationdata for steps in a process comprising a first portion and a secondportion wherein said first portion comprises the same data for all stepsin said process and said second portion comprises variable data.
 26. Aserver in accordance with claim 17, further comprising a processor forprocessing received items of transaction data to perform a said processassociated with task identification and by said data store, if saiditems of transaction data have been determined by said validator to bevalid.
 27. A server in accordance with claim 26, wherein said processoris operable to process said transaction data to generate or modify arecord in a database.
 28. A server in accordance with claim 17, whereinsaid items of transaction data received by said receiver comprises dataindicative of the smart card authorisation.
 29. A computer fordispatching a plurality of data sets comprising transaction data forperforming a process on a server, said computer comprising: a receiverfor receiving task identification data associated with steps in saidprocess to be performed on said server; a signature data generatoroperable for each of a plurality of items of transaction data togenerate signature data by encryption of a said item of transaction datacombined with said task identification data received by said receiver;and a dispatcher operable to dispatch for each item of transaction dataa data set comprising encrypted signature data encrypted by saidsignature data generator, said item of transaction data andidentification data.
 30. A computer in accordance with claim 29, whereinsaid signature data generator comprises: a message hash generatoroperable to process an item of transaction data combined with taskidentification data received by said receiver; and an encryptor operableto encrypt said generated message hash data.
 31. A computer inaccordance with claim 29, wherein said signature data generatorcomprises an encryptor operable to encrypt an item of transaction datacombined with a task identifier received by said receiver.
 32. A datacarrier storing computer implementable process steps for generatingwithin a programmable computer a server in accordance with any of claims17 to
 28. 33. A data carrier storing computer implementable processsteps for generating within a programmable computer, a computer inaccordance with any of claims 29 to
 31. 34. A data carrier in accordancewith claim 32 or 33, comprising a computer disc.
 35. A data carrier inaccordance with claim 32 or 33, comprising an electric signaltransferred via the Internet.
 36. A computer disc in accordance withclaim 34, wherein said computer disc comprises an optical,magneto-optical or magnetic disc.